home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1692.txt < prev    next >
Text File  |  1997-04-01  |  26KB  |  676 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         P. Cameron
  8. Request for Comments: 1692                  Xylogics, International Ltd.
  9. Category: Standards Track                                     D. Crocker
  10.                                                   Silicon Graphics, Inc.
  11.                                                                 D. Cohen
  12.                                                                  Myricom
  13.                                                                J. Postel
  14.                                                                      ISI
  15.                                                              August 1994
  16.  
  17.  
  18.                  Transport Multiplexing Protocol (TMux)
  19.  
  20. Status of this Memo
  21.  
  22.    This document specifies an Internet standards track protocol for the
  23.    Internet community, and requests discussion and suggestions for
  24.    improvements.  Please refer to the current edition of the "Internet
  25.    Official Protocol Standards" (STD 1) for the standardization state
  26.    and status of this protocol.  Distribution of this memo is unlimited.
  27.  
  28. Abstract
  29.  
  30.    One of the problems with the use of terminal servers is the large
  31.    number of small packets they can generate. Frequently, most of these
  32.    packets are destined for only one or two hosts.  TMux is a protocol
  33.    which allows multiple short transport segments, independent of
  34.    application type, to be combined between a server and host pair.
  35.  
  36. Acknowledgments
  37.  
  38.    This specification is the result of the merger of two documents: the
  39.    original TMux proposal which was the result of several discussions
  40.    and related initiatives through IETF working groups; and IEN 90 [1]
  41.    originally proposed by Danny Cohen and Jon Postel in May 1979.
  42.  
  43. Applicability Statement
  44.  
  45.    The TMux protocol is intended to optimize the transmission of large
  46.    numbers of small data packets that are generated in situations where
  47.    many interactive Telnet and Rlogin sessions are connected to a few
  48.    hosts on the network.  In these situations, TMux can improve both
  49.    network and host performance.  TMux is not intended for multiplexing
  50.    long streams composed of large blocks of data that are typically
  51.    transmitted by such applications as FTP.
  52.  
  53.    The TMux protocol may be applicable to other situations where small
  54.    packets are generated, but this was not considered in the design.
  55.  
  56.  
  57.  
  58. Cameron, Crocker, Cohen & Postel                                [Page 1]
  59.  
  60. RFC 1692                          TMux                       August 1994
  61.  
  62.  
  63.    The use of the TMux protocol in any other situation may require some
  64.    modification.
  65.  
  66. 1. Introduction
  67.  
  68.    When network designers consider which protocols generate the most
  69.    load, they naturally tend to consider protocols which transfer large
  70.    blocks of data (e.g., FTP, NFS).  What is often not considered is the
  71.    load generated by Telnet and Rlogin because of the assumption that
  72.    users type slowly and the packets are very small.  This is a grave
  73.    underestimation of the load on networks and hosts which have many
  74.    Telnet and Rlogin ports on multiple terminal servers.
  75.  
  76.    The problem stems from the fact that the work a host must do to
  77.    process a 1-octet packet is very nearly as much as the work it must
  78.    do to process a 1500-octet packet.  That is, it is the overhead of
  79.    processing a packet which consumes a host's resources, not the
  80.    processing of the data.
  81.  
  82.    In particular, communication load is not measured only in bits per
  83.    seconds but also in packets per seconds, and in many situation the
  84.    latter is the true performance limit, not the former.  The proposed
  85.    multiplexing is aimed at alleviating this situation.
  86.  
  87.    If one assumes that most users connected to a terminal server will be
  88.    connecting to only a few hosts, then it should be obvious that the
  89.    network and host load could be greatly reduced if traffic from
  90.    multiple users, destined for the same host, could be sent in the same
  91.    packet.
  92.  
  93.    TMux is designed to improve network utilization and reduce the
  94.    interrupt load on hosts which conduct multiple sessions involving
  95.    many short packets.  It does this by multiplexing transport traffic
  96.    onto a single IP datagram [2], thereby resulting in fewer, larger
  97.    packets.  TMux is highly constrained in its method of accomplishing
  98.    this task, seeking simplicity rather than sophistication.
  99.  
  100. 2. Protocol Design
  101.  
  102.    IP hosts may engage in the use of TMux transparently, and may even
  103.    switch back and forth between use of TMux and carriage of transport
  104.    segments in the usual, independent IP datagrams.
  105.  
  106.    TMux operates by placing a set of transport segments into the same IP
  107.    datagram.  Each segment is preceded by a TMux mini-header which
  108.    specifies the segment length and the actual segment transport
  109.    protocol.  The receiving host demultiplexes the individual transport
  110.    segments and presents them to the transport layer as if they had been
  111.  
  112.  
  113.  
  114. Cameron, Crocker, Cohen & Postel                                [Page 2]
  115.  
  116. RFC 1692                          TMux                       August 1994
  117.  
  118.  
  119.    received in the usual IP/transport packaging.  The transport layer
  120.    is, therefore, unaware of the special encapsulation which was used.
  121.  
  122.    Hence, a TMux message appears as:
  123.  
  124.      | IP hdr | TM hdr | Tport segment | TM hdr | Tport segment| ...|
  125.  
  126.    Where:
  127.  
  128.  
  129.    TM hdr         is a TMux mini-header and specifies the following
  130.                   Tport segment.
  131.  
  132.  
  133.    Tport segment  refers to the entire transport segment, including
  134.                   transport headers.
  135.  
  136.    The TMux Protocol is defined to allow the combining of transmission
  137.    units of different higher level protocols in one transmission unit of
  138.    a lower level protocol. Only segments with the same Internet Protocol
  139.    (IP) header, (with the possible exception of the protocol and check-
  140.    sum fields) may be combined. For example, the segment (H1, B1) and
  141.    the segment (H2, B2), where Hi and Bi are the headers and the bodies
  142.    of the segment, respectively, may be combined (multiplexed) only if
  143.    H=H1=H2. The combined TMux message is either (H, B1, B2) or (H, B2,
  144.    B1).
  145.  
  146.    The receiver of this combined message should treat it as if the two
  147.    original segments, (H,B1), and (H,B2), arrived separately.  It is
  148.    recommended, though not a requirement, that the segments in the TMux
  149.    message should be processed in the same order that they are in the
  150.    TMux message.
  151.  
  152.    The multiplexing is achieved by combining the individual segments,
  153.    (H,B1) through (H,Bn), into a single message.  This single message
  154.    has an IP header which is equal to H, but having in the PROTOCOL
  155.    field the value 18 which is the protocol number of the TMux protocol.
  156.    This IP header is followed by all the segments, B1 through Bn.  Each
  157.    segment, Bi, is preceded by a 4 octet TMux mini header. This contains
  158.    the number of the protocol to which this segment is addressed. It
  159.    also contains the total length of this segment, including this mini
  160.    header. Since this mini header is not otherwise protected by a check-
  161.    sum, it also includes a checksum field which just covers this mini
  162.    header.
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Cameron, Crocker, Cohen & Postel                                [Page 3]
  171.  
  172. RFC 1692                          TMux                       August 1994
  173.  
  174.  
  175. 2.1. IP Protocol field value
  176.  
  177.    TMux is indicated in an IP datagram by the Protocol (ID) value of 18
  178.    (22 octal), see [3].
  179.  
  180. 2.2. Header Format
  181.  
  182.    Each 4 octet TMux mini-header has the following general format:
  183.  
  184.                      +-------------------------------+
  185.                      |         Length high           |
  186.                      +-------------------------------+
  187.                      |          Length low           |
  188.                      +-------------------------------+
  189.                      |         Protocol ID           |
  190.                      +-------------------------------+
  191.                      |          Checksum             |
  192.                      +-------------------------------+
  193.                      |      Transport segment        |
  194.                      |       ...                     |
  195.                      |       ...                     |
  196.  
  197.    The LENGTH field specifies the octet count for this mini header and
  198.    the following transport segment, from 0-65535 octets.  Hence, the
  199.    length field has a minimum value of 4.  For segments that are larger
  200.    than the maximum allowed for TMux (see section 5.1), individual IP
  201.    datagrams should be sent.
  202.  
  203.    The Protocol ID field contains the value that would normally have
  204.    been placed in the IP header Protocol field.
  205.  
  206.    The 'Checksum' field is the XOR of the first 3 octets.
  207.  
  208.    To ensure that TCP, UDP and other segments keep their 32 bit
  209.    alignment, where the segments being multiplexed are not a multiple of
  210.    32 bits long, extra octets will be added to re-align the end of the
  211.    segment, and hence the next segment.  These octets will be ignored on
  212.    input.  This padding will not affect the LENGTH field, it will still
  213.    contain the real length of the segment.
  214.  
  215. 2.3. Sending Data
  216.  
  217.    Host endpoints may choose to use TMux at any time and in either (or
  218.    both) directions.  They also may switch back and forth between use of
  219.    TMux packaging and the usual individual IP datagrams for individual
  220.    transport associations.  The only barrier to the use of TMux is for
  221.    the sender to know whether TMux is supported by the receiver.  This
  222.    is important, since early use of TMux is likely to be limited.
  223.  
  224.  
  225.  
  226. Cameron, Crocker, Cohen & Postel                                [Page 4]
  227.  
  228. RFC 1692                          TMux                       August 1994
  229.  
  230.  
  231.    The easiest way to detect TMUX support is to only send TMux messages
  232.    to hosts from which a valid TMux message has already been received.
  233.    This then leaves the problem of one host starting the TMux
  234.    connection.  This is most easily accomplished by the host sending an
  235.    IP datagram with no data (i.e., with the IP total length field of
  236.    20), but with an IP Protocol field value of 18 for TMux.  This is
  237.    referred to as a TMux ENQ (enquiry) message.  The host receiving this
  238.    message then knows that the originator supports TMux, and can start
  239.    to send TMux messages. This will in turn cause the originator of the
  240.    ENQ message to start to use TMux.  If for any reason the receiver
  241.    does not intend to send TMux messages to the originator, but is
  242.    prepared to accept them, then it can reply with another ENQ message.
  243.  
  244.    If an ENQ message does not get a response, then it is reasonable to
  245.    resend the ENQ a while later in case the original ENQ message was
  246.    lost.  If this again is lost, the ENQ may be repeated as often as
  247.    needed, but the time between requests should increase exponentially
  248.    up to a limit of about 1 hour.  Suitable times between ENQs would be
  249.    15 seconds, 30 seconds, 60 seconds, 120 seconds etc.
  250.  
  251.    Note that this checking process does not need to impede any of the
  252.    transport (user) data, which may be sent as convenient, albeit in its
  253.    less-efficient IP datagram form.
  254.  
  255.    The only problem with this scheme is that a host which supports TMux
  256.    may stop supporting it, as might happen when the host is re-booted.
  257.    Other hosts need to learn of this change.  The solution to this is to
  258.    maintain a Time To Live (TTL) value for hosts from which TMux
  259.    messages have been received.  This TTL is a timed TTL, rather than a
  260.    count as used in the IP TTL field, and this time stamp is updated
  261.    every time a TMux message is received.  This can then be used to
  262.    expire the information held by TMux on the host after a suitable
  263.    time, e.g., 1 minute.
  264.  
  265.    This TTL time stamp is used as follows. When TMux is passed a segment
  266.    to be sent to a host, a check is made to see if the time to live has
  267.    expired.  If the TTL has not expired, the segment is sent in a TMux
  268.    message as normal.  If the TTL has expired, the host is marked as
  269.    being unable to TMux, but the segment is STILL sent as a TMux message
  270.    (i.e., with the normal delay to allow other segments to be
  271.    multiplexed).  If the host is really unable to TMux anymore (a rare
  272.    occurrence) then this segment will be timed out and retried by the
  273.    transport provider i.e., TCP.  Because the host was marked as not
  274.    able to TMux, the retry will be sent as a normal IP datagram.  If the
  275.    remote host is still able to TMux then it should send back TMux
  276.    traffic (even if it has been rebooted), typically a TCP window
  277.    update, and the local host will mark it as able to TMux again. This
  278.    way of operating removes any performance problem caused by
  279.  
  280.  
  281.  
  282. Cameron, Crocker, Cohen & Postel                                [Page 5]
  283.  
  284. RFC 1692                          TMux                       August 1994
  285.  
  286.  
  287.    continually dropping out of TMuxing and having to send probe
  288.    messages.  If the IP datagram to be sent is from UDP, then the remote
  289.    host may not send anything in reply. So for UDP this scheme will not
  290.    be any better than just stopping sending TMux messages to the host,
  291.    but it is also no worse.
  292.  
  293. 3.  Protocol Behavior
  294.  
  295. 3.1. Transport Flow Control
  296.  
  297.    TMux operates as an extension to the IP datagram protocol.  Hence, it
  298.    has no impact on most flow control mechanisms, since they operate at
  299.    the transport layer -- above TMux.
  300.  
  301. 3.2. Connection Management
  302.  
  303.    The concept of a connection pertains to certain transport protocols,
  304.    but not to IP or to TMux.  Hence, when connection management is
  305.    required by a transport protocol using TMux, it occurs in the same
  306.    fashion as it does for IP.  In fact, the transport protocol is not to
  307.    be aware that TMux is being used.
  308.  
  309. 3.3 Multiplexed Message Construction
  310.  
  311.    When a transport provider (e.g., TCP or UDP) sends a segment, TMux
  312.    first removes the IP header (if present) and adds a TMux mini-header
  313.    and the segment to the Multiplexed Message under construction for the
  314.    host specified by the destination address of the segment.
  315.  
  316.    When the first message to be transmitted is placed into the
  317.    Multiplexed Message under construction, a timer is started.  When the
  318.    timer expires, the Multiplexed Message under construction is
  319.    transmitted. This ensures that all segments available for sending
  320.    before the timer expires are sent in a single Multiplexed Message.
  321.    If, during construction of the Multiplexed Message, the buffer
  322.    holding the message fills, the Multiplexed Message is transmitted
  323.    immediately.
  324.  
  325.    The delay time should be user configurable; a reasonable time is 20
  326.    to 30 milliseconds.  The time period should be large enough to give a
  327.    reasonable probability of sending multiple segments but not so large
  328.    that the echo response time becomes a problem.  This suggests that
  329.    the upper limit for the timer is probably 1/10th second.  As the cost
  330.    of using timeouts on many systems is quite large, it is recommended
  331.    that a single timer be used and that all TMux messages under
  332.    construction are sent when the timer expires.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Cameron, Crocker, Cohen & Postel                                [Page 6]
  339.  
  340. RFC 1692                          TMux                       August 1994
  341.  
  342.  
  343.    Additionally, configuration options may limit the number of included
  344.    data segments or the maximum size of the Multiplexed Message before
  345.    it is transmitted.  It is also suggested that larger segments (e.g.,
  346.    those over 700 octets) should be sent as standard IP datagrams, and
  347.    not multiplexed.  This is to ensure that the delay caused by the TMux
  348.    timer does not put a delay on those segments for which it is
  349.    inadvisable.  The size of the largest segments to be multiplexed
  350.    should (if possible) be configurable.
  351.  
  352. 4. Protocol Example
  353.  
  354.    This example shows a TMux message consisting of three multiplexed
  355.    segments:
  356.  
  357.    A TCP segment consisting of a 20 octet TCP header, 5 octets of data
  358.    and 3 octets of padding.  Thus the length field is
  359.  
  360.              Mini header + TCP header + data
  361.            =     4       +     20     +  5
  362.            =     29
  363.  
  364.    The padding is NOT included in the length.
  365.  
  366.    A TCP segment consisting of a 20 octet TCP header, 4 octets of data.
  367.    This segment does not require padding.
  368.  
  369.    A UDP segment consisting of a 4 octet UDP header, 41 octets of data
  370.    and 3 octets of padding.
  371.  
  372.                      +-------------------------------+
  373.                      |         Length = 29           |
  374.                      |         (2 octets)            |
  375.                      +-------------------------------+
  376.                      |     Protocol ID = 6 (TCP)     |
  377.                      +-------------------------------+
  378.                      |          Checksum             |
  379.                      +-------------------------------+
  380.                      |         TCP Header            |
  381.                      |        (20 octets)            |
  382.                      +-------------------------------+
  383.                      |          TCP data             |
  384.                      |         (5 octets)            |
  385.                      +-------------------------------+
  386.                      |          Padding              |
  387.                      |         (3 octets)            |
  388.                      +-------------------------------+
  389.                      |         Length = 28           |
  390.                      |         (2 octets)            |
  391.  
  392.  
  393.  
  394. Cameron, Crocker, Cohen & Postel                                [Page 7]
  395.  
  396. RFC 1692                          TMux                       August 1994
  397.  
  398.  
  399.                      +-------------------------------+
  400.                      |     Protocol ID = 6 (TCP)     |
  401.                      +-------------------------------+
  402.                      |          Checksum             |
  403.                      +-------------------------------+
  404.                      |         TCP Header            |
  405.                      |        (20 octets)            |
  406.                      +-------------------------------+
  407.                      |          TCP data             |
  408.                      |         (4 octets)            |
  409.                      +-------------------------------+
  410.                      |         Length = 49           |
  411.                      |         (2 octets)            |
  412.                      +-------------------------------+
  413.                      |    Protocol ID = 17 (UDP)     |
  414.                      +-------------------------------+
  415.                      |          Checksum             |
  416.                      +-------------------------------+
  417.                      |         UDP Header            |
  418.                      |         (4 octets)            |
  419.                      +-------------------------------+
  420.                      |          UDP data             |
  421.                      |         (41 octets)           |
  422.                      +-------------------------------+
  423.                      |          Padding              |
  424.                      |         (3 octets)            |
  425.                      +-------------------------------+
  426.  
  427. 5. Implementation Suggestion
  428.  
  429. 5.1 Maximum TMux Message Size
  430.  
  431.    In section 3.3, a note is made about sending messages immediately if
  432.    the limit on TMux message size is reached.  On systems where Path MTU
  433.    Discovery (as per RFC 1191 [4]) has been implemented this should be
  434.    used to discover the maximum message size that can be transmitted,
  435.    and this should be used as the maximum TMux message size.
  436.  
  437. 5.2 Deciding Which Segments to Multiplex
  438.  
  439.    It is the responsibility of the sender to decide which segments
  440.    should be TMux'd and which should not.  For example, segments sent by
  441.    FTP should not normally be multiplexed.  In many situations, it may
  442.    be sensible to restrict the sessions that can be multiplexed to just
  443.    those involved in interactive traffic (Telnet and Rlogin) by
  444.    examining the source and destination TCP port numbers.  However, if a
  445.    segment that would not normally be multiplexed is to be sent and a
  446.    TMux message is already under construction, then the extra segment
  447.  
  448.  
  449.  
  450. Cameron, Crocker, Cohen & Postel                                [Page 8]
  451.  
  452. RFC 1692                          TMux                       August 1994
  453.  
  454.  
  455.    can be added to the TMux message under construction, and this
  456.    complete message should be sent immediately, rather than waiting for
  457.    the timer to expire.
  458.  
  459. 6. Implementation notes
  460.  
  461.    The following notes are the result of experience gained during the
  462.    testing of early implementations of TMux.  Whilst they do not form
  463.    part of the actual standard, they should be followed if possible to
  464.    ensure compatibility with other implementations.
  465.  
  466.    Because the TMux mini-header does not contain a TOS field, only
  467.    segments with the same IP TOS field should be contained in a single
  468.    TMux message.  As most systems do not use the TOS feature, this is
  469.    not a major restriction.  Where the TOS field is used, it may be
  470.    desirable to hold several messages under construction for a host, one
  471.    for each TOS value.
  472.  
  473.    Segments containing IP options should not be multiplexed.
  474.  
  475.    Only unicast addresses should be considered for multiplexing.
  476.  
  477.    Segments addressed to the loopback address (127.0.0.1) are not
  478.    candidates for multiplexing.
  479.  
  480.    Only segments with a source or destination port that is for an
  481.    interactive session (i.e., Telnet and Rlogin) should be considered
  482.    for multiplexing using TMux.
  483.  
  484.    If an error is discovered in a checksum of a TMux header, the rest of
  485.    the message, starting there, is ignored.  If an unknown PROTOCOL
  486.    field is discovered in any TMux header, this segment, and only this
  487.    one, is ignored.
  488.  
  489.    If the TMux implementation is continually sending TMux messages
  490.    containing exactly one segment (because is there is little traffic to
  491.    multiplex), then TMux may be turned off.  This implies that TMux may
  492.    be switched off when there is no congestion.
  493.  
  494.    To prevent intermediate nodes from fragmenting and reconstructing
  495.    TMux frames, implementations may want to set the "do not fragment"
  496.    flag in the IP datagram of TMux messages.
  497.  
  498.    If host B receives a TMux ENQ message from host A, but does not have
  499.    any data for host A, then it may also send back an ENQ message.
  500.    However, host A may send another ENQ message in response to this, so
  501.    causing B to respond and so on.  Thus if this facility is used, code
  502.    must be included to prevent this looping behavior happening.  Sending
  503.  
  504.  
  505.  
  506. Cameron, Crocker, Cohen & Postel                                [Page 9]
  507.  
  508. RFC 1692                          TMux                       August 1994
  509.  
  510.  
  511.    an ENQ in response to an ENQ is not recommended, except in special
  512.    circumstances.
  513.  
  514.    It is recommended that the following aspects of the TMux protocol be
  515.    user configurable:
  516.  
  517.       The maximum size of a segment that can be multiplexed by TMux.
  518.  
  519.       The delay between the first segment being placed into the message
  520.       under construction and the message being sent.
  521.  
  522. 7. Security Considerations
  523.  
  524.    Because TMux is effectively an extension to IP, it does not have any
  525.    more impact on site security than does IP.  Security should be dealt
  526.    with by upper layer protocols.
  527.  
  528.    Because some routers filter packets on the TCP port numbers, any
  529.    segments sent using TMux will not be subject to this filtering as it
  530.    will obscure the TCP port number However, larger segments for the
  531.    same TCP connection will still be sent as IP datagrams, and so will
  532.    be subject to filtering, thus giving rise to a potential problem.
  533.    For this reason, any routers that do not support TMux, but which do
  534.    support this type of filtering should not allow TMux messages through
  535.    (in either direction).  This will cause both hosts to think the other
  536.    does not support TMux, so all segments will be sent as IP datagrams,
  537.    thus eliminating this problem.
  538.  
  539.    A better solution to this problem, is for routers to understand the
  540.    TMux protocol, and to inspect each of the multiplexed segments and
  541.    remove those segments that fail the filtering.
  542.  
  543. 8. References
  544.  
  545.    [1] Cohen, D., and Postel, J., "Multiplexing Protocol", IEN 90,
  546.        USC/Information Sciences Institute,, May 1979.
  547.  
  548.    [2] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
  549.        Sciences Institute, September 1981.
  550.  
  551.    [3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
  552.        USC/Information Sciences Institute, March 1990.
  553.  
  554.    [4] Mogul, J., and S. Deering, "Path MTU discovery", RFC 1191, DECWRL
  555.        and Stanford University, November 1990.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Cameron, Crocker, Cohen & Postel                               [Page 10]
  563.  
  564. RFC 1692                          TMux                       August 1994
  565.  
  566.  
  567. 9. Authors' Addresses
  568.  
  569.        Peter Cameron
  570.        Xylogics International, Ltd.
  571.        Featherstone Rd.
  572.        Wolverton Mill
  573.        Milton Keynes
  574.        MK12 5RD
  575.        United Kingdom
  576.  
  577.        Phone: +44  908 222112
  578.        Fax:   +44  908 222115
  579.        EMail: cameron@xylint.co.uk
  580.  
  581.  
  582.        David Crocker
  583.        Silicon Graphics, Inc.
  584.        2011 N. Shoreline Blvd.
  585.        P.O. Box 7311
  586.        Mountain View, CA 94039-7311
  587.        USA
  588.  
  589.        Phone: +1 415 390 1804
  590.        Fax:   +1 415 962 8404
  591.        EMail: dcrocker@sgi.com
  592.  
  593.  
  594.        Danny Cohen
  595.        Myricom
  596.        325 N. Santa Anita Ave.
  597.        Arcadia, CA 91006
  598.        USA
  599.  
  600.        Phone: +1 818 821 5555
  601.        EMail: Cohen@myricom.com
  602.  
  603.  
  604.        Jon Postel
  605.        USC/Information Sciences Institute
  606.        4676 Admiralty Way
  607.        Marina del Rey, CA  90292-6695
  608.        USA
  609.  
  610.        Phone: +1 310 822 1511
  611.        Fax:   +1 310 823 6714
  612.        EMail: Postel@ISI.EDU
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Cameron, Crocker, Cohen & Postel                               [Page 11]
  619.  
  620. RFC 1692                          TMux                       August 1994
  621.  
  622.  
  623. 10. Discussion List
  624.  
  625.        There is a discussion list for this protocol, which for
  626.        historical reasons is called:
  627.  
  628.            cmp-id@xylint.co.uk
  629.  
  630.    Requests to join the list should be sent to:
  631.  
  632.            cmp-id-request@xylint.co.uk
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Cameron, Crocker, Cohen & Postel                               [Page 12]
  675.  
  676.